Skip to content

RFC - definition of a runner class using as much of the existing code as possible#404

Draft
syntron wants to merge 102 commits intoOpenModelica:masterfrom
syntron:syntron_RFC
Draft

RFC - definition of a runner class using as much of the existing code as possible#404
syntron wants to merge 102 commits intoOpenModelica:masterfrom
syntron:syntron_RFC

Conversation

@syntron
Copy link
Contributor

@syntron syntron commented Jan 11, 2026

Content (lots of changes / these will be splitted into several PRs if the general approach is approved):

  • OMCSession.py: rename real OMCPath* classes as privat (start with '_')
  • OMCSession: define OMCPathDummy and OMCSessionDummy => no OMC server
  • ModelExecution.py: include all code related to model execution (from OMCsession*; ModelicaSystemCmd)
  • ModelicaSystemDoE.py: seperate file for this class
  • ModelicaSystemDoE.py: use ModelicaSystem / reduce number of arguments to init
  • ModelicaSystem(Base).py: split getOutputs() and getContinuous() to Initial and Final data
  • ModelicaSystem(Base).py: getOutputs*() / getContinuous*() - always return np.float64
  • ModelicaSystemBase.py: define a basic version of ModelicaSystem
  • ModelicaSystemRunner.py: definition of a 'runner' class using ModelicaSystemBasic / OMCSessionDummy (see PR Enable the usage of a pre-built model executables by ModelicaSystemRunner #401)
  • test_ModelicaSystemRunner.py: test case for ModelicaSystemRunner
  • test_*: update of test cases based on above listed changes

Compared to PR #401 this solution:

  • still uses the existing OMPython requirements (dependencies of the Runner class; i.e. numpy, etc.)
  • shares nearly all code with the current definitions (by using OMCPathDummy and OMCSessionDummy)
  • uses | instead of Union

Further changes could do additional modifications such that the 3rd party packages (ZMQ) are not needed at all in the runner code path.

All tests are running without error / tested in https://github.com/syntron/OMPython/actions/runs/20865402893

Please comment!

@syntron
Copy link
Contributor Author

syntron commented Feb 9, 2026

Some status update on this PR - the main points are:

The code defined here updates the internal structure of OMPython such that:

  • generic code is separated in ABC classes
  • derived code exists for OMC usage and Runner usage
  • a compatibility layer exists such that the interface of OMPython 4.0.0 is (basically) supported; this is tested using the original unittests from v4.0.0

Furthermore, as OMCPath is working only for Python >= 3.12, another dimension exists. There is a dummy implementation of OMCPath for Python < 3.12 such that most of the functionality can also be used here. See PR #401 for a hint that even older Python version are used (Python 3.10 or even lower).

These changes could be the baseline for a new documentation (see https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/ompython.html). My idea was to include these changes as 4.x.0 and create a cut at the next release (or keep some kind of compatibility layer alive).

(partly from the discussion in PR #387)

@syntron
Copy link
Contributor Author

syntron commented Feb 9, 2026

The failed test is due to Windows - it runs well for v4.0.0 (see: https://github.com/syntron/OMPython/actions/runs/21842400755) and 4.x.x (see: https://github.com/syntron/OMPython/actions/runs/21841418638)

@syntron
Copy link
Contributor Author

syntron commented Feb 13, 2026

This is a final version of my changes to get a 'runner' functionality to OMPython. The main parts:

  • Compatibility with OMPython v4.0.0
  • Split fucntions into ABC / OMC / Runner
  • Split the large files into smaller onces based on the usage

This PR will be splitted into smaller steps.

@syntron syntron marked this pull request as ready for review February 13, 2026 23:20
@syntron syntron force-pushed the syntron_RFC branch 2 times, most recently from be89d52 to b20568b Compare February 15, 2026 11:17
@adeas31 adeas31 requested review from adeas31 and arun3688 February 16, 2026 16:30
Copy link
Collaborator

@arun3688 arun3688 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good

@syntron
Copy link
Contributor Author

syntron commented Feb 16, 2026

looks good

OK; I will create small parts for review & merge; there are some changes on top to restructure the two main files

@adeas31
Copy link
Member

adeas31 commented Feb 18, 2026

looks good

OK; I will create small parts for review & merge; there are some changes on top to restructure the two main files

Sorry I haven't got time to look into this yet.
As I understand, you will break this into new smaller PRs for review & merge, right?

@syntron
Copy link
Contributor Author

syntron commented Feb 18, 2026

Sorry I haven't got time to look into this yet. As I understand, you will break this into new smaller PRs for review & merge, right?

yes - this is the plan; the one RFC is way too big / too much changes to get an easy overview ...

@syntron
Copy link
Contributor Author

syntron commented Feb 18, 2026

Summary of the changes in these RFC; the elements will be provided as single PRs.

Basic concept / plan:

  • Define a Runner variant which allows to run compiled (binary) models without usage of an OMC server
  • Split all code into 3 parts: ABC (generic code), OMC related, Runner related
  • Define a compatibility layer which provides OMPython v4.0.0 compatibility

This means for some period of time, the new interface and the compatibility layer can exist in parallel (versions
4.x.x). Thus, errors can be found & fixed and people can adapt to the new interface before it is the only option.

Steps for the implementation (see PRs below):

  • (A) independent PRs based on current master; together these build the baseline for (B) and further
  • (B) split classes into ABC / OMC related
  • (C) define Runner part
  • (D) use unittests from v4.0.0 as reference / prepare compatibility layer
  • (E) prepare & split files (move classes around)
  • (F) cleanup after changes
  • (G) move all depreciated code into the compatibility layer
  • (H) removal of compatibility layer for a OMPython v5.0.0 (merged later)

I tried to order the PRs based on the steps (A) to (H) but some will be out of order. If the PRs are merged, please try
to follow the numbering.

PRs based on this RFC (using the branch name in my fork syntron:OMPython as reference; I will use this comment to link the PRs step by step):

(step A)

  • (A001) simplify_workflow_Test
  • (A002) OMParser
  • (A003) OMTypedParser
  • (A004) ModelicaSystem_okey_oval
  • (A005) OMCPath_remove_stat
  • (A006) OMCSession_small_fixes
  • (A007) ModelicaSystem_cleanup
  • (A008) ModelicaSystem_getContinuous_getOutputs
  • (A009) ModelicaSystem_small_fixes
  • (A000) use_function_keyword_arguments
  • (A011) update_init_docstring
  • (A012) reorder_imports
  • (A013) ModelicaSystemDoE
  • (A014) ModelExecution
  • (A015) ModelicaSystem_check_model_executable

(step B)

  • (B001) ModelicaSystem_split
  • (B002) ModelicaSystemDoE_split
  • (B003) OMCSession_OMPathABC
  • (B004) OMCSession_OMSessionABC

(step C)

  • (C001) Runner_definitions

(step D)

  • (D001) OMSession_small_fixes
  • (D002) OMSessionZMQ_move
  • (D003) OMCPath_improve
  • (D004) OMSessionRunner
  • (D005) OMCSession_classes_update
  • (D006) ModelicaSystem_small_fixes2
  • (D007) test_v400
  • (D008) v400_compatibility_layer

(step E)

  • (E001) update_tests
  • (E002) prepare_restructure
  • (E003) restructure

(step F)

  • (F001) restructure_cleanup

=> status syntron_RFC

step G & H are still to be reordered

@syntron
Copy link
Contributor Author

syntron commented Feb 18, 2026

PRs of step A:

(A001) simplify_workflow_Test - PR #411 - UPDATED
(A002) OMParser - PR #412
DONE - (A003) OMTypedParser - PR #413
DONE - (A004) ModelicaSystem_okey_oval - PR #414
(A005) OMCPath_remove_stat - PR #415
(A006) OMCSession_small_fixes - PR #416
(A007) ModelicaSystem_cleanup - PR #417
(A008) ModelicaSystem_getContinuous_getOutputs - PR #418
(A009) ModelicaSystem_small_fixes - PR #419
(A011) update_init_docstring - PR #421
(A012) reorder_imports - PR #422
(A013) ModelicaSystemDoE - PR #423

moved to the end / rebase needed:
(A010) use_function_keyword_arguments - PR #420
(A014) ModelExecution - PR #424
(A015) ModelicaSystem_check_model_executable - PR #425 (on top of PR #424)

The final state can be found at https://github.com/syntron/OMPython/tree/mergeA

* ModelicaSystemRunner & OMCPath
* ModelicaSystemRunner & OMPathRunnerLocal
* ModelicaSystemRunner & OMPathRunnerBash
* ModelicaSystemRunner & OMPathRunnerBash using docker
* ModelicaSystemRunner & OMPathRunnerBash using WSL (not tested!)
* OMCPath & OMCSessionZMQ
* OMCPath & OMCSessionLocal
* OMCPath & OMCSessionDocker
* OMCPath & OMCSessionWSL (not tested!)
* OMPathLocal & OMCSessionRunner
* OMPathBash & OMCSessionRunner
* OMPathBash & OMCSessionRunner in docker
* OMPathBash & OMCSessionRunner in WSL (not tested!)
reason:
* it is only a test for OMC / not OMPython specific
* furthermore, it is run automatically via cron job (= FMITest)
@syntron
Copy link
Contributor Author

syntron commented Feb 26, 2026

@joewa any feedback from your side?

@Sonyoyo could you test the runner functionality for WSL? I do not have this option available to me ...

@adeas31
Copy link
Member

adeas31 commented Feb 26, 2026

@adeas31 I'm working with smaller commits which build up the PR in serveral steps; however, if these are merged into one commit, were is a high risk for merge conflicts for later PRs especially if these build on top of each other. Would it be OK if I create single step PRs for section B to E (see #404 (comment))? I would keep the details locally but only push one-commit PRs ...

Yeah sounds good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants